1. Technical Field
This invention is concerned with transmission of data from a sending station to a receiving terminal. More particularly, it envisages transmission over a telecommunications network where the transmitted bit-rate that the network can support is initially undetermined.
2. Related Art
The situation addressed can arise, for example, when the rate fluctuates owing to the use of a congestion control mechanism. For example, the TCP/IP system uses IP (Internal Protocol) for transport. This is a connectionless service and simply transports transmitted packets to a destination. TCP (Transmission Control Protocol) is an overlay to this service and brings in the idea of a connection; the sending station transmits a packet and waits for an acknowledgement from the receiving terminal before transmitting another (or in the event of no acknowledgement within a timeout period, it retransmits the packet). More importantly (in the present context) it embodies a congestion control algorithm where it begins with a small packet size and progressively increases the packet size until packet loss occurs, whereupon it reduces the size again. After this initial “slow start” phase, the algorithm continues to increase the packet size (albeit more gradually) backing off whenever packet loss occurs; necessarily this involves some cyclic variation of the packet size. A description of TCP is to be found in “Computer Networks”, by Andrew S. Tanenbaum, third edition, 1996, pp. 521-542.
Another common protocol is UDP (User Data Protocol). This does not have a congestion control mechanism of its own, but it has been proposed to add one to it, the so-called “TCP-Friendly Rate Protocol (TFRC) described in the Internet Engineering Task Force (IETF) document RFC3448. This aims to establish an average transmitting data rate similar to that which the TCP algorithm would have achieved, but with a smaller cyclic variation. It too exhibits the same “slow start” phase.
One drawback of this slow start system is that the transmitting station will not “know” what bit-rate the network will provide until the slow start phase is complete—which may take (depending on the round-trip time of the network) as much as several seconds. For some applications this does not matter, but in others it does: for example, when streaming video from a server which provides a choice of compression rates, the server cannot make an informed decision at the outset about which rate to choose. In the past, one method of dealing with this has been that the server starts by transmitting the lowest quality stream and switches up to a higher rate if and when it finds that the network can support it.